FIG. 1 depicts three primary types of storage systems. As will be made more clear immediately below, what differentiates each of the storage systems from one another is the mechanism that is used to access the stored information.
FIG. 1a shows basic object storage. In the case of an object store, a requestor 101 requests access to a specific item of stored information (“an object”) from the object store 102 by way of an “object ID” 103. An object ID is a uniquely identifying reference of a specific object with the store (e.g. a randomly assigned alphanumeric character). Another type of store that conceptually has a large degree of overlap with an object store is a “key-value” store. By definition, a key-value store maps individually stored information (i.e., the “values”) to individual keys that are uniquely assigned to the values. A specific set of stored values are accessed by providing the store with the key for those values. Thus, the “key” corresponds to an “object ID” and the “values” correspond to an “object”.
FIG. 1b shows file directory based storage. In the case of file directory based storage individual items of stored information are kept in files 104_1 through 104_N. Files are organized into a directory where any sub-directory 106_1 through 106_M can include one or more files or one or more lower sub-directories. A specific item of information is obtained by accessing its file. The file is accessed by articulating the path through the directory that leads to the file. For example, in the exemplary directory of FIG. 1b, file 104_3 is accessed by articulating “C/FOO/BAR/NOTES”.
FIG. 1c shows block based storage. In the case of block based storage, the storage resource is viewed as being broken down into contiguous blocks 107_1 through 107_N. A specific item of information is accessed by identifying the block where it resides. A common type of block storage is a “thin provisioning” system in which a block is identified by an offset within a larger “logical” storage resource. Thin provisioned systems have been traditionally used to more efficient use of physical storage resources as unused block segments do not occupy physical storage space. For example, a logical file (e.g., as contemplated by an operating system) may include active data portions or “stripes” where actual data resides and “unused” portions where no substantive data resides.
The unused portions may correspond, for instance, to regions that have not been written to yet. The “real” data that was been written to is written in “stripes”. For example, if FIG. 1 represents a logical file that spans offset 80 through 106, stripes 80-87 and stripes 100-106 contain real data and are stored in physical storage while offset values 88-99 are understood to contain 0s that are not actually stored in physical storage.
While FIGS. 1a-1c depict core physical storage solutions by themselves, FIG. 1d shows a fundamental usage case or implementation of any of these core storage solutions. FIG. 1d shows a traditional “database” storage implementation. As observed in FIG. 1d, the traditional database storage implementation includes a database interface 108, an indexing layer 109 and a storage layer 110.
The database interface layer 108 accepts queries to the database storage (e.g., according to some type of predefined structured query language (e.g., SQL) or other query format). A common feature of queries is that they often identify data by its content rather than a particular address where the sought for data is found. For example, a query submitted through interface 108 might ask for all email addresses having a specific string (e.g., “@abc.com”). It is the role of the indexing and storage layers 109, 110 to actually find the targeted information.
The indexing layer 109 exists to speedup lookups into the storage layer 110. As a point of comparison, without the indexing layer 109, a query for a particular item of information within the storage layer 110 would be accomplished primarily by scrolling through each item of information kept by the storage layer 110 until the sought for information was found.
The function of the indexing layer 109 is similar to the index at the end of a textbook. With input criteria specifying the sought after information (e.g., “@abc.com”), the index returns with one or more pointers or other information useable to fetch the specifically requested information from the storage layer 110. Thus the indexing layer 109 can be viewed as a mechanism for effectively searching the contents of the underlying storage layer 110.
The storage layer 110 corresponds to the resources used to actually store the information and can be implemented with any of the storage systems discussed above with reference to FIGS. 1a through 1c. 
FIG. 1e depicts the implementation of a relational database. As is understood in the art a relational database is typically contemplated as a collection of tables. The individual rows of the various tables are viewed as the records that are kept by the relational database. The columns of a particular table are used to keep the various data items for a particular row. For example, referring to table 120, if each row represents a particular person, a first column may be used to keep the person's name, a second column may be used to keep the person's phone number, a third column may be used to keep the person's email address, etc. Rows whose data content are defined by the same set of columns are logically viewed as being kept within the same table.
Typically, one column of a table is identified as the “primary key” used to identify a particular row within the table. For example, continuing with the example above where each row represents a person, one column of a table may be used for a “userid” that uniquely identifies the person. With the userid for a particular person, the row in the table for the particular person can be easily fetched. In this sense, the userid also acts as a primary key for accessing the table as well. Here, a primary key may include a combination of an identifier of the table and an identifier of a specific row within the table. The columns of a table may also include the primary keys of (rows of) other tables to establish “relationships” between records. For example, if the columns of table 120 table keep the personal information for specific people, one of these columns may include the primary key for another table 121 that keeps records on the employers of these people.
Thus, if a logic operation desires to know specific information about an employer of a particular individual, the logic operation may first access the person's record from table 120 with the userid for that person and obtain the primary key for the row in table 121 that contains information about the person's employer.
Relational databases can also be “queried” for specific information. For example, the relational database discussed above could be queried to provide the names of all people who have a specific area code in their phone number. Here, the first table 120 would be accessed, all the records having the sought for area code would be extracted and the information from the name column of these extracted records would be provided as the query result.
Note that an indexing layer 122 could be used to speed up the querying process. That is, rather than simply access the table 121 and scroll row-by-row through it for records having the desired area code, instead, an index layer 121 could be built on top of the tables 120, 121 that is designed to provide the primary keys of people based on their area code. Here, the index 121 can take the form of a B+ tree whose nodes are associated with specific area code numeric ranges with a narrower range being specified moving down through the tree. Eventually the leaf pages of the B+ tree are reached that provide specific primary keys for specific people having a specific area code. In a basic approach there is a separate index for every column in a table so that any query for any item of information within the table can be sped up as described above. Of course, any changes to the records in the table will need to be reflected in the index.